Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system

ABSTRACT

Use of a smart proxy as a wrapper around a stub in a distributed system. Instead of receiving a stub as a result of a remote procedure call, a caller receives a smart proxy including the stub as an embedded object. The smart proxy performs predefined processing associated with a remote procedure call, the processing possibly occurring before, during, or after a response to the call.

REFERENCE TO RELATED APPLICATIONS

The following identified U.S. patent applications are relied upon andare incorporated by reference in this application as if fully set forth.

Provisional U.S. Patent Application No. 60/076,048, entitled“Distributed Computing System,” filed on Feb. 26, 1998.

U.S. Pat. No. 6,263,350, entitled “Method and System for LeasingStorage.”

U.S. Pat. No. 6,247,026, entitled “Method, Apparatus, and Product forLeasing of Delegation Certificates in a Distributed System.”

U.S. Pat. No. 6,421,704, entitled “Method, Apparatus and Product forLeasing of Group Membership in a Distributed System,” filed on Mar. 20,1998.

U.S. Pat. No. 6,016,500, entitled “Leasing for Failure Detection.”

U.S. patent application Ser. No. 09/144,933, entitled “Method forTransporting Behavior in Event Based System,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,272,559 entitled “Deferred Reconstruction of Objects andRemote Loading for Event Notification in a Distributed System.”

U.S. Pat. No. 6,487,607, entitled “Methods and Apparatus for RemoteMethod Invocation,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,134,603, entitled “Method and System for DeterministicHashes to Identify Remote Methods.”

U.S. Pat. No. 6,598,094, entitled “Method and Apparatus for DeterminingStatus of Remote Objects in a Distributed System,” filed on Mar. 20,1998.

U.S. Pat. No. 6,237,024, entitled “Suspension and Continuation of RemoteMethods.”

U.S. Pat. No. 6,182,083, entitled “Method and System for Multi-Entry andMulti-Template Matching in a Database.”

U.S. patent application Ser. No. 09/044,839, entitled “Method and Systemfor In-Place Modifications in a Database,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,578,044, entitled “Method and System for TypesafeAttribute Matching in a Database,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,185,611, entitled “Dynamic Lookup Service in aDistributed System,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,560,656, entitled “Apparatus and Method for ProvidingDownloadable Code for Use in Communicating with a Device in aDistributed System,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,832,223, entitled “Method and System for FacilitatingAccess to a Lookup Service,” filed on Mar. 20, 1998.

U.S. Pat. No. 6,466,947, entitled “Apparatus and Method for DynamicallyVerifying Information in a Distributed System,” filed on Mar. 20, 1998.

U.S. patent application Ser. No. 09/044,936, entitled “An InteractiveDesign Tool for Persistent Shared Memory Spaces,” filed on Mar. 20,1998.

U.S. Pat. No. 6,438,614, entitled “Polymorphic Token-Based Control,”filed on Mar. 20, 1998.

U.S. Pat. No. 6,138,238, entitled “Stack-Based Access Control.”

U.S. Pat. No. 6,226,746, entitled “Stack-Based Security Requirements.”

U.S. Pat. No. 6,282,652, entitled “Per-Method Designation of SecurityRequirements.”

FIELD OF THE INVENTION

The present invention relates to a system and method for transmittingobjects between machines in a distributed system and more particularlyrelates to transmission of a representation of a remote object includingcode for local processing.

BACKGROUND OF THE INVENTION

Distributed programs which concentrate on point-to-point datatransmission can often be adequately and efficiently handled usingspecial-purpose protocols for remote terminal access and file transfer.Such protocols are tailored specifically to the one program and do notprovide a foundation on which to build a variety of distributed programs(e.g., distributed operating systems, electronic mail systems, computerconferencing systems, etc.).

While conventional transport services can be used as the basis forbuilding distributed programs, these services exhibit manyorganizational problems, such as the use of different data types indifferent machines, lack of facilities for synchronization, and noprovision for a simple programming paradigm.

Distributed systems usually contain a number of different types ofmachines interconnected by communications networks. Each machine has itsown internal data types, its own address alignment rules, and its ownoperating system. This heterogeneity causes problems when buildingdistributed systems. As a result, program developers must include inprograms developed for such heterogeneous distributed systems thecapability of ensuring that information is handled and interpretedconsistently in different machines.

However, one simplification is afforded by noting that a largeproportion of programs use a request and response interaction betweenprocesses where the initiator (i.e. program initiating a communication)is blocked out until the response is returned and is thus idle duringthis time. This can be modeled by a procedure call mechanism betweenprocesses. One such mechanism is referred to as the remote procedurecall (RPC).

RPC is a mechanism for providing synchronized communication between twoprocesses (e.g., program, applet, etc.) running on the same machine ordifferent machines. In a simple case, one process, e.g., a clientprogram, sends a message to another process, e.g., a server program. Inthis case, it is not necessary for the processes to be synchronizedeither when the message is sent or received. It is possible for theclient program to transmit the message and then begin a new activity, orfor the server program's environment to buffer the incoming messageuntil the server program is ready to process a new message.

RPC, however, imposes constraints on synchronism because it closelymodels the local procedure call, which requires passing parameters inone direction, blocking the calling process (i.e., the client program)until the called procedure of the server program is complete, and thenreturning a response. RPC thus involves two message transfers, and thesynchronization of the two processes for the duration of the call.

The RPC mechanism is usually implemented in two processing parts usingthe local procedure call paradigm, one part being on the client side andthe other part being on the server side. Both of these parts will bedescribed below with reference to FIG. 1.

FIG. 1 is a diagram illustrating the flow of call information using anRPC mechanism. As shown in FIG. 1, a client program 100 issues a call(step 102). The RPC mechanism 101 then packs the call as arguments of acall packet (step 103), which the RPC mechanism 101 then transmits to aserver program 109 (step 104). The call packet also contains informationto identify the client program 100 that first sent the call. After thecall packet is transmitted (step 104), the RPC mechanism 101 enters await state during which it waits for a response from the server program109.

The RPC mechanism 108 for the server program 109 (which may be the sameRPC mechanism as the RPC mechanism 101 when the server program 109 is onthe same platform as the client program 100) receives the call packet(step 110), unpacks the arguments of the call from the call packet (step111), identifies, using the call information, the server program 109 towhich the call was addressed, and provides the call arguments to theserver program 109.

The server program receives the call (step 112), processes the call byinvoking the appropriate procedure (step 115), and returns a response tothe RPC mechanism 108 (step 116). The RPC mechanism 108 then packs theresponse in a response packet (step 114) and transmits it to the clientprogram 100 (step 113).

Receiving the response packet (step 107) triggers the RPC mechanism 101to exit the wait state and unpack the response from the response packet(step 106). RPC 101 then provides the response to the client program 100in response to the call (step 105). This is the process flow of thetypical RPC mechanism modeled after the local procedure call paradigm.Since the RPC mechanism uses the local procedure call paradigm, theclient program 100 is blocked at the call until a response is received.Thus, the client program 100 does not continue with its own processingafter sending the call; rather, it waits for a response from the serverprogram 109.

The Java™ programming language is an object-oriented programminglanguage that is typically compiled into a platform-independent format,using a bytecode instruction set, which can be executed on any platformsupporting the Java virtual machine (JVM). This language is described,for example, in a text entitled “The Java Language Specification” byJames Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996, which isincorporated herein by reference. The JVM is described, for example, ina text entitled “The Java Virtual Machine Specification,” by TimLindholm and Frank Yellin, Addison Wesley, 1996, which is incorporatedherein by reference. Java and Java-based trademarks are trademarks orregistered trademarks of Sun Microsystems, Inc. in the United States andother countries.

Because the JVM may be implemented on, any type of platform,implementing distributed programs using the JVM significantly reducesthe difficulties associated with developing programs for heterogenousdistributed systems. Moreover, the JVM uses a Java remote methodinvocation system (RMI) that enables communication among programs of thesystem. RMI is explained in, for example, the following document, whichis incorporated herein by reference: Remote Method InvocationSpecification, Sun Microsystems, Inc. (1997), which is available viauniversal resource locator (URL)http://wwwjavasoft.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html.

FIG. 2 is a diagram illustrating the flow of objects in anobject-oriented distributed system 200 including machines 201 and 202for transmitting and receiving method invocations using the JVM. Insystem 200, machine 201 uses RMI 205 for responding to a call for object203 by converting the object into a byte stream 207 including anidentification of the type of object transmitted and data constitutingthe object. While machine 201 is responding, to the call for object 203,a process running on the same or another machine in system 200 maycontinue operation without waiting for a response to its request.

Machine 202 receives the byte stream 207. Using RMI 206, machine 202automatically converts it into the corresponding object 204, which is acopy of object 203 and which makes the object available for use by aprogram executing on machine 202. Machine 202 may also transmit theobject to another machine by first converting the object into a bytestream and then sending it to the third machine, which alsoautomatically converts the byte stream into the corresponding object.

The communication between these machines sometimes involves, forexample, repeated calls for the same information. These calls are madeto a local proxy, which acts as a surrogate for the remote object in theaddress space of the client. Such a proxy will service the call bymaking a network request to the server object. Repeated calls to thesame server object through a proxy can generate considerable networktraffic, increasing the time and expense of obtaining the information.Accordingly, a need exists for a technique that reduces the amount ofnetwork communication in, for example, such a case.

SUMMARY OF THE INVENTION

A method consistent with the present invention transmits a request for aparticular object. A response to the request is received, the responseincluding code used to construct a representation of the requestedobject, the construction creating an object for processing calls to theobject, local to the requesting object, using the representation.

Another method consistent with the present invention receives at amachine a request for a particular object. A response to the request istransmitted, the response including first code for constructing arepresentation of the object and including an indication of second codefor processing, such that the construction creates an object forprocessing calls to the object, local to the requesting object, usingthe representation.

An apparatus consistent with the present invention transmits a requestfor a particular object. The apparatus receives a response to therequest, the response including code used to construct a representationof the requested object, the construction creating an object forprocessing calls to the object, local to the requesting object, usingthe representation.

Another apparatus consistent with the present invention receives at amachine a request for a particular object. The apparatus transmits aresponse to the request, the response including first code forconstructing a representation of the object and including an indicationof second code for processing, such that the construction creates anobject for processing calls to the object, local to the requestingobject, using the representation.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are incorporated in and constitute a part ofthis specification and, together with the description, explain theadvantages and principles of the invention. In the drawings,

FIG. 1 is a diagram illustrating the flow of call information using anRPC mechanism;

FIG. 2 is a diagram illustrating the transmission of objects in anobject-oriented distributed system;

FIG. 3 is a diagram of an exemplary distributed processing system thatcan be used in an implementation consistent with the present invention;

FIG. 4 is a diagram of an exemplary distributed system infrastructure;

FIG. 5 is a diagram of a computer in a distributed system infrastructureshown in FIG. 4;

FIG. 6 is a block diagram of a distributed network for use indownloading smart proxies;

FIG. 7 is a flow chart of a process for downloading smart proxieswithin, for example, the distributed network shown in FIG. 6; and

FIG. 8 is a flow chart of a process for changing the processingperformed by a smart proxy.

DETAILED DESCRIPTION Overview

Instead of receiving a proxy that only makes network requests to theobject for which it is a surrogate, a machine in a distributed systemreceives a smart proxy. Such a proxy can respond to calls on the objectfor which it is a surrogate without making any network calls to increaseprogram efficiency, or perform processing before making a network callor after the completion of the network call to increase programfunctionality. The term proxy generally refers to code or othermechanism used to act as a surrogate for a remote object in the addressspace of a machine,

Systems transferring stubs and associated smart proxies may use avariant of an RPC or RMI, passing arguments and return values from oneprocess to another process each of which may be on different machines.The term “machine” is used in this context to refer to a physicalmachine or a virtual machine. Multiple virtual machines may exist on thesame physical machine. Examples of RPC systems include distributedcomputed environment (DCE) RPC and Microsoft distributed common objectmodel (DCOM) RPC. A memory stores the stub and associated smart proxy,and this memory may include secondary sources such as a disk orreceiving objects from the Internet.

Distributed Processing System

FIG. 3 illustrates an exemplary distributed processing system 300 whichcan be used in an implementation consistent with the present invention.In FIG. 3, distributed processing system 300 contains three independentand heterogeneous platforms 301, 302, and 303 connected in a networkconfiguration represented by network cloud 319. The composition andprotocol of the network configuration represented by cloud 319 is notimportant as long as it allows for communication of the informationbetween platforms 301, 302 and 303. In addition, the use of just threeplatforms is merely for illustration and does not limit animplementation consistent with the present invention to the use of aparticular number of platforms. Further, the specific networkarchitecture is not crucial to embodiments consistent with thisinvention. For example, another network architecture that could be usedin an implementation consistent with this invention would employ oneplatform as a network controller to which all the other platforms wouldbe connected.

In the implementation of distributed processing system 300, platforms301, 302 and 303 each include a processor 316, 317, and 318respectively, and a memory, 304, 305, and 306, respectively. Includedwithin each memory 304, 305, and 306, are applications 307, 308, and309, respectively, operating systems 310, 311, and 312, respectively,and RMI components 313, 314, and 315, respectively.

Applications 307, 308, and 309 can be applications or programs that areeither previously written and modified to work with, or that arespecially written to take advantage of, the services offered by animplementation consistent with the present invention. Applications 307,308, and 309 invoke operations to be performed in accordance with animplementation consistent with this invention.

Operating systems 310, 311, and 312 are typically standard operatingsystems tied to the corresponding processors 316, 317, and 318,respectively. The platforms 301, 302, and 303 can be heterogenous. Forexample, platform 301 has an UltraSparc® microprocessor manufactured bySun Microsystems, Inc. as processor 316 and uses a Solaris® operatingsystem 310. Platform 302 has a MIPS microprocessor manufactured bySilicon Graphics Corp. as processor 317 and uses a Unix operating system311. Finally, platform 303 has a Pentium microprocessor manufactured byIntel Corp. as processor 318 and uses a Microsoft Windows 95 operatingsystem 312. An implementation consistent with the present invention isnot so limited and could accommodate homogenous platforms as well.

Sun, Sun Microsystems, Solaris, Java, and the Sun Logo are trademarks orregistered trademarks of Sun Microsystems, Inc. in the United States andother countries. UltraSparc and all other SPARC trademarks are usedunder license and are trademarks of SPARC International Inc. in theUnited States and other countries. Products bearing SPARC trademarks arebased upon an architecture developed by Sun Microsystems, Inc.

Memories 304, 305, and 306 serve several functions, such as generalstorage for the associated platform. Another function is to storeapplications 307, 308, and 309, RMI components 313, 314, and 315, andoperating systems 310, 311, and 312 during execution by the respectiveprocessor 316, 317, and 318. In addition, portions of memories 304, 305,and 306 may constitute shared memory available to all of the platforms301, 302, and 303 in network 319. Note that RMI components 313, 314, and315 operate in conjunction with a JVM, which is not shown for thepurpose of simplifying the figure.

Distributed System Infrastructure

Systems and methods consistent with the present invention may alsooperate within a particular distributed system 400, which will bedescribed with reference to FIGS. 4 and 5. This distributed system 400is comprised of various components, including hardware and software, to(1) allow users of the system to share services and resources over anetwork of many devices; (2) provide programmers with tools andprogramming patterns that allow development of robust, secureddistributed systems; and (3) simplify the task of administering thedistributed system. To accomplish these goals, distributed system 400utilizes the Java programming environment to allow both code and data tobe moved from device to device in a seamless manner. Accordingly,distributed system 400 is layered on top of the Java programmingenvironment and exploits the characteristics of this environment,including the security offered by it and the strong typing provided byit.

In distributed system 400 of FIGS. 4 and 5, different computers anddevices are federated into what appears to the user to be a singlesystem. By appearing as a single system, distributed system 400 providesthe simplicity of access and the power of sharing that can be providedby a single system without giving up the flexibility and personalizedresponse of a personal computer or workstation. Distributed system 400may contain thousands of devices operated by users who aregeographically disperse, but who agree on basic notions of trust,administration, and policy.

Within an exemplary distributed system are various logical groupings ofservices provided by one or more devices, and each such logical groupingis known as a Djinn. A “service” refers to a resource, data, orfunctionality that can be accessed by a user, program, device, oranother service and that can be computational, storage related,communication related, or related to providing access to another user.Examples of services provided as part of a Djinn include devices, suchas printers, displays, and disks; software, such as programs orutilities; information, such as databases and files; and users of thesystem.

Both users and devices may join a Djinn. When joining a Djinn, the useror device adds zero or more services to the Djinn and may access,subject to security constraints, any one of the services it contains.Thus, devices and users federate into a Djinn to share access to itsservices. The services of the Djinn appear programmatically as objectsof the Java programming environment, which may include other objects,software components written in different programming languages, orhardware devices. A service has an interface defining the operationsthat can be requested of that service, and the type of the servicedetermines the interfaces that make up that service.

Distributed system 400 is comprised of computer 402, a computer 404, anda device 406 interconnected by a network 408. Device 406 may be any of anumber of devices, such as a printer, fax machine, storage device,computer, or other devices. Network 408 may be a local area network,wide area network, or the Internet. Although only two computers and onedevice are depicted as comprising distributed system 400, one skilled inthe art will appreciate that distributed system 400 may includeadditional computers or devices.

FIG. 5 depicts computer 402 in greater detail to show a number of thesoftware components of distributed system 400. One skilled in the artwill appreciate that computer 404 or device 406 may be similarlyconfigured. Computer 402 includes a memory 502, a secondary storagedevice 504, a central processing unit (CPU) 506, an input device 508,and a video display 510. Memory 502 includes a lookup service 512, adiscovery server 514, and a Java runtime system 516. The Java runtimesystem 516 includes the Java RMI system 518 and a JVM 520. Secondarystorage device 504 includes a Java space 522.

As mentioned above, distributed system 400 is based on the Javaprogramming environment and thus makes use of the Java runtime system516. The Java runtime system 516 includes the Java API libraries,allowing programs running on top of the Java runtime system to access,in a platform-independent manner, various system functions, includingwindowing capabilities and networking capabilities of the host operatingsystem. Since the Java API libraries provide a single common API acrossall operating systems to which the Java runtime system is ported, theprograms running on top of a Java runtime system run in aplatform-independent manner, regardless of the operating system orhardware configuration of the host platform. The Java runtime system 516is provided as part of the Java software development kit available fromSun Microsystems, Inc. of Mountain View, Calif.

JVM 520 also facilitates platform independence. JVM 520 acts like anabstract computing machine, receiving instructions from programs in theform of bytecodes and interpreting these bytecodes by dynamicallyconverting them into a form for execution such as object code, andexecuting them. RMI 518 facilitates remote method invocation by allowingobjects executing on one computer or device to invoke methods of anobject on another computer or device. Both RMI and the JVM are alsoprovided as part of the Java software development kit.

Lookup service 512 defines the services that are available for aparticular Djinn. That is, there may be more than one Djinn and,consequently, more than one lookup service within distributed system400. Lookup service 512 contains one object for each service within theDjinn, and each object contains various methods that facilitate accessto the corresponding service. Lookup service 512 is described in U.S.patent application entitled “Method and System for Facilitating Accessto a Lookup Service,” which was previously incorporated herein byreference.

Discovery server 514 detects when a new device is added to distributedsystem 400, during a process known as boot and join (or discovery), andwhen such a new device is detected, the discovery server passes areference to lookup service 512 to the new device so that the new devicemay register its services with the lookup service and become a member ofthe Djinn. After registration, the new device becomes a member of theDjinn, and as a result, it may access all the services contained inlookup service 512. The process of boot and join is described in U.S.patent application entitled “Apparatus and Method for providingDownloadable Code for Use in Communicating with a Device in aDistributed System,” which was previously incorporated herein byreference.

A Java space 522 is an object repository used by programs withindistributed system 400 to store objects. Programs use a Java space 522to store objects persistently as well as to make them accessible toother devices within distributed system 400. Java spaces are describedin U.S. patent application Ser. No. 08/971,529, entitled “DatabaseSystem Employing Polymorphic Entry and Entry Matching,” assigned to acommon assignee, and filed on Nov. 17, 1997, which is incorporatedherein by reference. One skilled in the art will appreciate that anexemplary distributed system 400 may contain many lookup services,discovery servers, and Java spaces.

Data Flow in a Distributed Processing System

FIG. 6 is a block diagram of an object-oriented distributed network 600connecting machines 601 and 606, such as computers or virtual machinesexecuting on one or more computers, or the machines described withreference to FIGS. 3, 4, and 5. Network 600 transmits proxies, some ofwhich may be smart proxies. A smart proxy includes code for performingprocessing associated with a call. For example, a smart proxy mayperform a caching operation for read-only data for later reference. Whena call is made for that data, the smart proxy may obtain it locally andprovide it to a user without making another call for the data, which mayoccur transparent to the user. An example of such read-only data is aparticular installation time. The first time a call is made for theinstallation time, for example, a smart proxy locally caches that value,and when a subsequent call is made for the installation time, the smartproxy locally retrieves the value.

Another example of smart proxy processing involves use of a serializedobject for transmitting data to a data bank storing information. In thisexample, a call is made to a smart proxy, which receives an object,serializes the object on the client machine into an array of bytes, andtransmits the array of bytes to a server. The server only stores theserialized object, avoiding the requirement to download code, and itprovides a key for the object to the client machine. When the clientmachine wants to retrieve the data, the smart proxy transmits the key tothe server, receives in response the serialized object, reconstructs theobject, and provides it to the user.

Other examples of uses of smart proxies include processing fordebugging, call logging, and monitoring system performance. Anotherexample involves the use of a smart proxy for local data verification,as explained in U.S. patent application Ser. No. 09/044,932, filed onMar. 20, 1998, assigned to a common assignee, and entitled “Apparatusand Method for Dynamically Verifying Information in a DistributedSystem,” which is incorporated herein by reference. Many other uses forsmart proxies are possible for performing processing associated with acall.

Network 600 includes a client machine 601 containing RMI 602 andassociated code 603. A server machine 606 includes RMI 607 and remoteobject 608. In operation, RMI 602 transmits a call or request 609 to RMI607, requesting a particular stub object. RMI 607 returns a response 610including requested stub 605 embedded within a smart proxy 604. Theresponse may be transmitted as a stream. Streams used in the Javaprogramming language, including input and output streams, are known inthe art and an explanation, which is incorporated herein by reference,appears in, for example, a text entitled “The Java Tutorial:Object-Oriented Programming for the Internet,” pp. 325-53, by MaryCampione and Kathy Walrath, Addison-Wesley, 1996.

The response may include information so that client machine 601 canreconstruct the stub object in smart proxy 604. When a set of objecttypes is limited and is the same on machines 601 and 606, a receivingmachine typically requires the object's state and a description of itstype because the object's code is already present on all networkmachines. Alternatively, machine 606 uses RMI 607 to provide moreflexibility, allowing code to be moved when necessary along withinformation or the object's state and type. Additionally, a transmittingmachine may include in the object an identification of the type ofobject transmitted, the data constituting the state of the object, and anetwork-accessible location in the form of a URL for code that isassociated with the object. URLs are known in the art and anexplanation, which is incorporated herein by reference, appears in, forexample, a text entitled “The Java Tutorial: Object-Oriented Programmingfor the Internet,” pp. 494-507, by Mary Campione and Kathy Walrath,Addison-Wesley, 1996.

When client machine 601 receives response 610, it identifies the type oftransmitted object. Machine 601 contains its own RMI 602 and code 603for processing of objects, and it may create stub object 605 using theobject type, the state information, and code for the object. If code forthe object is not resident or available on machine 601 and the stubobject does not contain the code, RMI 602 may use a URL from the objectto locate the code and transfer a copy of the code to client machine601. Because the code is bytecodes and is therefore portable, clientmachine 601 can load the code into RMI 602 to reconstruct the object.Thus, client machine 601 can reconstruct an object of the appropriatetype even if that kind of object has not been present on the machinebefore.

When creating stub object 605, RMI 602 does not necessarily know thatthe stub is itself a smart proxy 604. Smart proxy 604 may performprocessing at client machine 601 before or after response 610 and maysupply all processing without resorting to call 609 to the object forwhich the proxy acts. Therefore, smart proxy 604 may perform allprocessing locally when client machine 601 makes a call or request 611to invoke a method on smart proxy 604. These proxies are downloadable bythe same methods as disclosed in U.S. patent application Ser. No.08/950,756, filed on Oct. 15, 1997, and entitled “DeferredReconstruction of Objects and Remote Loading in a Distributed System,”which is incorporated herein by reference.

Transmission of Smart Proxies

FIG. 7 is a flow chart of a process 700 for downloading and using smartproxies within, for example, the distributed network shown in FIG. 6. Aclient machine transmits a call or request for a particular object (step701), and a server machine receives the call (step 702). In response,the server machine returns a smart proxy with an embedded stub (step703), and the proxy acts as a representation of the requested object.After receiving the smart proxy, the client machine invokes a method onit (step 704). According to the code within the smart proxy, the clientmachine containing the smart proxy determines if preprocessing isrequired (step 705). If so, the processing is performed locally by theclient machine using the smart proxy (step 706).

The client machine then determines if the method called on the smartproxy may be serviced locally (step 707). If so, the client machineperforms the local processing for the call (step 711). If not, theclient machine calls the remote object (step 708). The remote processingis performed (step 709), and the result of the remote processing isreturned to the client machine (step 710).

The client machine determines, according to code in the smart proxy, ifpost-processing as a result of the call is required (step 712). If so,it locally performs the post-processing using code in the smart proxy(step 713). The smart proxy then returns the method call result (step714) in response to the call on the smart proxy in step 704.

FIG. 8 is a flow chart of a process 800 for changing the processingperformed by a smart proxy. When processing is invoked (step 801), aclient machine determines if updated processing is required (step 802).Such information may be contained within the smart proxy itself in thatit may determine when or under what particular circumstances it requiresupdated processing code. If updated processing is required, the code forthat processing is downloaded and the smart proxy is updated at theclient machine to perform that processing (step 803). The smart proxythen performs at the client machine the processing according to theupdated code (step 804).

Machines implementing the steps shown in FIGS. 7 and 8 may includecomputer processors for performing the functions, as shown in FIGS. 3,4, 5, and 6. They may include modules or programs configured to causethe processors to perform the above functions. They may also includecomputer program products stored in a memory. The computer programproducts may include a computer-readable medium or media havingcomputer-readable code embodied therein for causing the machines toperform functions described above. The computer readable media mayinclude sequences of instructions which, when executed by a processor,cause the processor to securely address a peripheral device at anabsolute address by performing the method described in thisspecification. The media may also include a data structure for use inperforming the method described in this specification.

Although the illustrative embodiments of the systems consistent with thepresent invention are described with reference to a computer systemimplementing the Java programming language on the JVM specification, theinvention is equally applicable to other computer systems processingcode from different programming languages. Specifically, the inventionmay be implemented with both object-oriented and nonobject-orientedprogramming systems. In addition, although an embodiment consistent withthe present invention has been described as operating in the Javaprogramming environment, one skilled in the art will appreciate that thepresent invention can be used in other programming environments as well.

While the present invention has been described in connection with anexemplary embodiment, it will be understood that many modifications willbe readily apparent to those skilled in the art, and this application isintended to cover any adaptations or variations thereof. For example,different labels or definitions for the smart proxies may be usedwithout departing from the scope of the invention. This invention shouldbe limited only by the claims and equivalents thereof.

What is claimed is:
 1. A method for processing calls to a server objectlocally by a processor at a smart proxy residing in a memory at a clientmachine, the method comprising: obtaining the smart proxy at the clientmachine, the smart proxy including stub code corresponding to a stubobject for the server object that is used to construct a representationof the stub object for the server object in the smart proxy in thememory at the client machine and the smart proxy including processingcode executable by a processor at the client machine for processingcalls to the server object locally at the stub object in the smart proxyas a representation of the server object at the client machine;constructing the representation of the stub object for the server objectin the smart proxy in the memory at the client machine using the stubcode; and processing one or more calls to the server object locally atthe stub object in the smart proxy using the processor at the clientmachine using the processing code of the smart proxy at the clientmachine to generate a response to the one or more calls withoutcommunicating the one or more calls to a server machine having theserver object.
 2. The method of claim 1, further including: processingadditional calls to the server object at a server machine whenprocessing said additional calls cannot be completed locally using theprocessor at the client machine using the stub object in the smart proxyas a representation of the server object at the client machine.
 3. Themethod of claim 1, further including: downloading, to the clientmachine, update code to update the processing code.
 4. A method forsharing objects between a client machine and a server machine in adistributed system for processing calls to the server machine locally atthe client machine, comprising: sending a request for a server objectfrom the client machine to the server machine; and responsive to therequest, sending a smart proxy from the server machine to the clientmachine, the smart proxy including: stub code used to construct a stubobject corresponding to the server object in the smart proxy in a memoryat the client machine, and an indication of processing code forprocessing calls to the server object in the smart proxy using aprocessor at the client machine; wherein when the stub object in thememory at the client machine is constructed and the processing code isexecuted in the smart proxy by the processor on the client machine, thestub object in the smart proxy at the client machine intercepts at leastone call to the server object without transmitting the at least one callto the server object residing on the server and processes the at leastone call locally in the smart proxy using the processor at the clientmachine to generate a response to the at least one call using the stubobject in the memory at the client machine and the processing code. 5.The method of claim 4, further including: using the stub code by thesmart proxy at the client machine to construct the stub object in thesmart proxy at the client machine.
 6. The method of claim 4, furtherincluding: downloading processing code to the client machine using theindication to update the processing code executed in the smart proxy atthe client machine for processing the at least one call to the serverobject locally in the smart proxy at the client machine using the stubobject at the client machine.
 7. The method of claim 4, furtherincluding: sending additional calls to the server object at the servermachine when processing of the additional calls cannot be completedlocally in the smart proxy at the client machine; and processing theadditional calls to the server object at the server machine whenprocessing of the additional calls cannot be completed locally at theclient machine using the stub object at the client machine.
 8. Themethod of claim 4, further including: receiving the request for theserver object at the server machine; and receiving the response from theserver machine at the client machine after processing the request to theserver object at the server machine.
 9. A system for processing calls toa server object locally at a smart proxy residing at a client machine,comprising: a server machine having the server object in a server memoryof the server machine for processing calls at a server processor at theserver machine and generating a response; wherein the client machine:(i) obtains a smart proxy from the server machine, the smart proxyincluding stub code for constructing a stub object in the smart proxyfor storage in a client memory at the client machine that is arepresentation of the server object and processing code forconfiguration of a client processor at the client machine for processingcalls to the server object locally in the smart proxy using the clientprocessor at the client machine, (ii) constructs the stub object in thesmart proxy in the client memory at the client machine using the stubcode, and (iii) processes at least one call to the server object locallyin the smart proxy using the client processor at the client machineusing the processing code to generate a response to the at least onecall locally at the client machine without communicating the at leastone call to the server machine; and a network connecting the clientmachine and the server machine.
 10. The system of claim 9, wherein theserver machine is configured to process additional calls to the serverobject when processing of the additional calls cannot be completedlocally in the smart proxy at the client machine using the stub objectin the smart proxy at the client machine.
 11. The system of claim 9,wherein the client machine is further configured to download update codeto update the processing code.
 12. A system for sharing objects in adistributed system for processing calls to a server machine locally at aclient machine, comprising: the client machine configured to send arequest for a server object to the server machine; the server machineconfigured to send, responsive to the request, a smart proxy to theclient machine, the smart proxy including: stub code for constructing astub object corresponding to the server object in the smart proxy in amemory at the client machine, and an indication of processing code forconfiguration of a processor at the client machine for processing callsto the server object in the smart proxy using the stub object at theprocessor at the client machine such that the stub object in the smartproxy at the client machine processes one or more calls to the serverobject locally in the smart proxy using the processor at the clientmachine to generate a response to the one or more calls without sendingthe one or more calls to the server machine, and a network connectingthe client machine and the server machine.
 13. The system of claim 12,wherein the client machine is further configured to construct the stubobject from the stub code.
 14. The system of claim 12, wherein theclient machine is further configured to download code to update theprocessing code.
 15. The system of claim 12, wherein the server machineis further configured to process additional calls to the server objectat the server machine when processing the additional calls cannot becompleted locally in the smart proxy at the client machine using thestub object.
 16. The system of claim 12, wherein the client machine isfurther configured to send the request from the client machine to theserver machine, and to receive the smart proxy from the server machine;and wherein, the server machine is further configured to receive therequest for the server object.